Soooo I know you put effort into this, but I still have reservations. The Gentoo side of it seems rather heavy maintenance-wise and also size-wise. Compare with this:

# syntax=ghcr.io/project-dalec/dalec/frontend:latest
# docker build -f bcc-container.yml --target=noble/container -t bcc .

name: bcc-container
description: BCC container
license: Apache-2.0
website: https://iovisor.github.io/bcc/
packager: Flatcar Linux
version: 0.1.0
revision: 1

dependencies:
  runtime:
    bpfcc-tools:

That can be built on just about anything with Docker. The Ubuntu 24.04 image weighs 422MB vs 1.13GB for the Gentoo one. To get the latest version, make an API call to Repology:

curl -f -H "User-Agent: Flatcar BCC builder" https://repology.org/api/v1/project/bcc-bpf | jq -r '.[] | select(.subrepo == "noble/main") | .version'

I also wondered whether the C implementation of execsnoop would work. This would be a lot leaner. I tested it, and it does. It needs CONFIG_DEBUG_INFO_BTF, but that was backported into the previous three LTS releases. The only problem is that the -l argument doesn't work properly. See iovisor/bcc#5486.

If we did go with that option, it could potentially even be done as a sysext with Dalec. That weighs a whole 13MB. Unfortunately, /usr/sbin is a directory rather than a symlink on Ubuntu, so it might upset the wider system, but nothing visibly fell over while I tried it.

I've got a potential plan C in the works. Entirely static binaries built on Alpine to be published in the sysext bakery. Gentoo Prefix might have been nice here, but we're not ready for that yet. This still suffers from the -l issue, but I can probably fix and patch that.

@chewi @krnowak something I've been thinking: what about dropping this test in favor of Inspektor Gadget tests? We have this one but it's really outdated and not accurate anymore: https://github.com/flatcar/mantle/blob/main/kola/tests/bpf/local-gadget.go

As there is a sysext for IG, I think it would make sense to test eBPF features using IG directly. I'm pretty sure we can find the execsnoop equivalent here: https://inspektor-gadget.io/docs/latest/gadgets/

My bakery sysext is all but done, but I'd be happy to drop it if IG makes more sense, and I think it might. I'd forgotten that we already have it as a sysext. I don't really know anything about BPF or IG though.

That turned out to be easier than expected.

sudo ig run trace_exec:latest --host -F "proc.comm=docker,args~ps"

Or this to match ps more exactly. a0 is non-breaking space.

sudo ig run trace_exec:latest --host -F $'args=/usr/bin/docker\u00a0ps'

I've tried it on a recent Flatcar as well as LTS 4081.3.6.

It fetches the gadget live. Hopefully that's not an issue for Kola. You can pin it to a version, but it should ideally match the IG version. Maybe latest would be simpler.

That turned out to be easier than expected.

sudo ig run trace_exec:latest --host -F "proc.comm=docker,args~ps"

Or this to match ps more exactly. a0 is non-breaking space.

sudo ig run trace_exec:latest --host -F $'args=/usr/bin/docker\u00a0ps'

I've tried it on a recent Flatcar as well as LTS 4081.3.6.

It fetches the gadget live. Hopefully that's not an issue for Kola. You can pin it to a version, but it should ideally match the IG version. Maybe latest would be simpler.

Great, thanks for giving a shot. :)

I'm fine of using latest for the versions (of IG and/or the gadget) like so we can easily detect the issue. Is the gadget an OCI artifact, if yes where is it stored (just to know if we need to mirror it).

It's stored at ghcr.io/inspektor-gadget/gadget/trace_exec:latest. Seems you can pass your own address with ig run.

It's stored at ghcr.io/inspektor-gadget/gadget/trace_exec:latest. Seems you can pass your own address with ig run.

It's fine then, it was mainly to be sure it's not on Docker hub (to not be rate limited)

Just in case there's any doubt over who's working on this, I have something partially done now.

Closing in favour of #791.